Enable autocommit in GremlinServer#3423
Conversation
| * On error: roll back the transaction so that partial mutations are not persisted. | ||
|
|
||
| This auto-commit behavior ensures that users who do not use explicit transactions still get durable writes on success | ||
| and clean rollback on failure. Graph system providers implementing their own server or HTTP endpoint must replicate |
There was a problem hiding this comment.
Since we are using "must", is there a consequence if they don't (Exception)? Can we document that?
There was a problem hiding this comment.
I'll change the wording to should, but no there are no consequences as to the user it would just look like it worked even though it failed.
| .get(GraphSONTokens.VALUEPROP).get(0) | ||
| .get(GraphSONTokens.VALUEPROP).intValue()); | ||
| } | ||
| } |
There was a problem hiding this comment.
Is there also a way to test stale open transactions?
There was a problem hiding this comment.
This would be hard to do as you can't make this happen in the normal flow since implicit transactions always attempt to rollback or commit and explicit transactions happen on a separate pool completely. We'd need some sort of mock server that has this flaw built into it so I'm going to leave this out for now if that is ok with you.
There was a problem hiding this comment.
Could any of these lines throw an error and should be in the rollback try catch in this case?
There was a problem hiding this comment.
This is a good point. I'll move the try block up to include the script eval in case gremlin-groovy is used.
|
VOTE +1 |
| own transaction semantics apply. Each traversal executes within its own transaction as managed by the graph | ||
| implementation itself. Transactional requests participate in a transaction opened via `g.tx().begin()`, where the | ||
| client explicitly controls the lifecycle through `g.tx().commit()` and `g.tx().rollback()`. | ||
| Non-transactional requests (those without a `transactionId`) behave as self-contained units of work. If the underlying |
There was a problem hiding this comment.
In the provider docs we wrote about "graphs that don't support transactions" and here we talk about "non-transactional". I wonder if we should avoid that language and just better introduce the notion of implicit and explicit transactions and talk only in those terms. In this way, all graphs have a transaction and they all support implicit (i.e. auto-commit, sessionless, non-transactional, etc. in the old parlance) and may support explicit (i.e. manual commit, session, transactional, etc. in the old parlance). In this way we don't drag back any of the older terminology.
|
VOTE +1 pending comment resolution. |
This behaves the same as the TraversalOpProcessor would have in the 3.x line. All traversals are now transactional if the underlying Graph supports transactions. Traversals that aren't explicitly in a transaction are now wrapped into their own implicit transaction and the server will autocommit on sucess and rollback on failure. Assisted-by: Kiro:claude-opus-4-6
5 participants
This behaves the same as the TraversalOpProcessor would have in the 3.x line. All traversals are now transactional if the underlying Graph supports transactions. Traversals that aren't explicitly in a transaction are now wrapped into their own implicit transaction and the server will autocommit on sucess and rollback on failure.
Assisted-by: Kiro:claude-opus-4-6